安安，今年的鐵人賽，我想寫幾篇文章來說明TDD 這件事情，且用 TDD KATA 來入門 Golang 並在最後探索出如何和AI一起做TDD。

首先，如標題所示要進入TDD就先來大致上的了解他一下，以下會用 What, Why, How 來認識以及了解甚麼是TDD。

What：什麼是測試驅動開發 (TDD)？

如果用一句話來概括 TDD，那就是：

在寫任何 Production Code 之前，先為它寫一個會失敗的測試。

這聽起來可能有點違反直覺。 一般來說我們習慣的流程是「寫程式 -> 手動測試 -> 修改 -> 再測試」，那為什麼要這麼麻煩，先寫一個測試而且還要讓它錯誤？
這正是 TDD 的有趣的所在，它反轉我們一般的開發流程，且有一套自己的開發循環 ：

紅燈 (Red) -> 綠燈 (Green) -> 重構 (Refactor)

• 紅燈 (Red):
  寫一個「小小的」、會失敗的測試案例。這個測試定義了我們「下一步」想要實現的功能。因為功能還沒寫，所以執行測試時，它理所當然地會亮起代表失敗的「紅燈」。
• 綠燈 (Green):
  給自己30秒，透過改寫 production code 讓這個測試通過。那為甚麼是30秒呢? 那是為了以 「最少量」 的production code 來通過測試，這個階段的我們，目標是盡快讓燈變綠，哪怕程式碼寫得有點「笨」。
• 重構 (Refactor):
  現在，我們有了一個通過測試。我們可以有安全感地回來，改善剛剛寫的程式碼的結構、移除重複、提升可讀性，同時確保測試燈號「維持綠燈」。

這三個步驟構成了一個微小但完整的開發循環。我們將在接下來的日子裡，周而復始地跳著這支「紅-綠-重構」之舞，看著我們的軟體功能在一個個穩固的循環中逐步成長。

Why：我們為何需要 TDD ？

花時間先寫測試，到底能帶來什麼好處？

1. TDD 提供給開發者滿滿的安全感
   想像一下，你正在維護一個龐大的系統。當你修改了 A 模組的一個小角落後，是否會怕東怕西，深怕不小心弄壞了遠在天邊的 B 模組？
   TDD 徹底解決了這個問題。當你為系統建立了全面的測試覆蓋後，這套測試就是你修改 code 時最強大的靠山。每當你新增功能或進行重構，只需執行一次測試指令，就能在幾秒鐘內知道你的修改是否破壞了任何既有功能。這種「隨時可以驗證一切正常」的安全感，就是 TDD 帶給開發者最寶貴的禮物。它讓開發者敢於重構、敢於擁抱變化。

2. TDD 是一份永遠不會過期的「活文件」
   是否也曾接手過沒有文件、或文件早已過時的專案？ 只能透過追蹤程式碼來猜測它的原始意圖呢?。
   一份寫得好的測試，本身就是一份最精準、最即時的技術文件。當你想了解某個函式的功能時，直接去看它的測試案例即可。測試案例會清楚地告訴你：

   • 在給定「這個輸入」時，它應該回傳「那個輸出」。
   • 在遇到「某種邊界條件」時，它會拋出「什麼樣的錯誤」。
     這份文件是由程式碼構成的，只要產品程式碼一變動導致行為不符，對應的測試就會立刻失敗。它永遠與程式碼的實際行為保持同步，是一份真正「活著」的文件。

How： 怎麼實踐 TDD？

理解了循環，我們還需要掌握每一步的心態：

• 跳到「紅燈」時：像個需求分析師。

  • 目標： 精確定義「一小步」需求。
  • 心態： 我現在要驗證什麼？輸入是什麼？預期輸出是什麼？一次只專注於一個失敗的原因。寫一個「恰好」會失敗的測試，不多也不少。

• 跳到「綠燈」時：像個衝刺的運動員。

  • 目標： 用最快、最簡單的方式讓測試通過。
  • 心態： 「先求有，再求好」。此刻不要考慮設計、不要想著優雅。哪怕用 if/else 硬刻一個答案也沒關係。我們的唯一目標就是熄滅紅燈。

• 跳到「重構」時：像個有潔癖的藝術家。

  • 目標： 在測試的保護下，清理程式碼。
  • 心態： 程式碼有沒有重複？命名是否清晰？結構是否可以更簡潔？這一步才是展現你程式碼設計功力的地方。因為你知道，只要不小心改壞了，測試會立刻告訴你。

關鍵心態：破除「TDD 會拖慢開發速度」的迷思

「聽起來不錯，但我沒時間寫測試，老闆追殺得緊啊！」

這可能是對 TDD 最大，也最常見的誤解。
短期來看，為了寫一個功能，開發者確實要先花時間寫測試，感覺上「多做了一件事」。但從整個開發週期來看，TDD 是一種「預先支付」的時間投資，它會在後期帶來數倍的回報。

傳統開發模式的時間分佈可能是：

開發 (20%) + 除錯 (40%) + 手動測試 (20%) + 修改整合 (20%)

而 TDD 模式則是：

寫測試 (20%) + 寫程式 (15%) + 重構 (15%) + 整合 (5%)

明顯可看出: TDD 將大量消耗在「除錯」和「手動驗證」上的時間，轉移到了更有價值的「設計」與「自動化驗證」上。 你花在Debug (通靈) 上的時間越少，真正的開發速度就越快。

今日總結

以上就是對於TDD 最最最粗略的解說，如果真的有興趣想了整完整的新法，不妨去拜讀 Kent Beck 大哥的文章或是書籍，都是滿滿的乾貨 ~~~

• What: TDD 是「紅燈 -> 綠燈 -> 重構」的開發循環。
• Why: 它為我們提供了「安全網」與「活文件」，讓我們能自信地開發與重構。
• How: 在每個階段扮演不同角色，精準、快速、優雅地完成循環。
• Mindset: TDD 不是成本，而是節省未來時間的最佳投資。

預告：Day 2 - 工欲善其事 - 搭建 Golang 開發與測試環境
我們將一步步在電腦上安裝好 Golang，並設定好我們的 VS Code，為接下來的程式碼實戰做好萬全準備。